Users may store user data as objects (e.g., files) in a storage system. As users change their objects, e.g., add or delete files, update files, and the like, the objects on the storage are changed to reflect the changes made by the users. Furthermore, users may want access to their objects as the objects existed at some point in time in the past. For instance, users may desire to access restore points of their data for a variety of reasons, such as in the case of accidental deletion of an object, corruption of an object, or the like. In such a case, a user may need to access a snapshot or other restore point of the user's data as it existed a point in time prior to the accidental deletion, corruption, etc.
Conventionally, taking a snapshot of user data entailed copying all of the contents of the user data at a point in time and storing the snapshot for future use. Snapshots may be taken at scheduled intervals, on demand, or based on various other techniques. However, taking snapshots in this manner consumes considerable computing resources and a large quantity of storage capacity.
Another conventional technique of taking snapshots includes saving metadata about what the system looks like at a particular time. According to this technique, a server may save a list of objects that exist at a particular time, but does not make copies of the content of the objects. Instead, the server prevents deletion or replacement of objects that are referenced by any snapshot metadata. This technique also has several drawbacks, such as consuming storage space for the metadata for each snapshot, consuming computing resources to generate the snapshot, and possibly maintaining numerous versions of the same object in the storage.
In both of the above-discussed conventional techniques of taking a snapshot, the actual snapshots themselves need to be generated, stored, managed, and eventually cleaned up. In addition, the data may be changing while the snapshot is being taken, which may present an additional challenge.